Dev - Request to Use a Distributed Version Control System When Code Base Changes

[Vinay Agarwal]

Hello,

 

May I request to use a distributed version control system (monotone, DARCS, mercurial, bazaar-ng etc.) when the code base is switched over to Apache?

 

Problem:

OFBiz is a fast changing project and expected to maintain its pace for the next year or so. A “significant” customization of OFBiz may require multiple engineers, significant development time, and need for maintaining local changes in a version control system. If such an effort chooses to develop from a snapshot of OFBiz, it is likely to miss out on constant improvements and may require a large “merge” effort eventually. If the effort chooses to be in sync with OFBiz constantly (like me), then local version control becomes very difficult.

 

Solution:

The so-called distributed version control systems allow local repositories, local changes, and sync capabilities with the main repository. There are many such open-source products and I can help investigate the best option.

 

The catch:

None of them have a “complete” Eclipse plugin or a GUI mode. DARCS has a very primitive eclipse plugin but not sure where that effort is headed.

 

Regards,

Vinay Agarwal

 

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

Vinay,

How is what these offer better than the SubVersion/SVN capabilities in this area? We currently use SVN and plan to continue using it after the Apache move.

-David


Vinay Agarwal wrote:

> Hello,
>
>  
>
> May I request to use a distributed version control system (monotone,
> DARCS, mercurial, bazaar-ng etc.) when the code base is switched over to
> Apache?
>
>  
>
> Problem:
>
> OFBiz is a fast changing project and expected to maintain its pace for
> the next year or so. A “significant” customization of OFBiz may require
> multiple engineers, significant development time, and need for
> maintaining local changes in a version control system. If such an effort
> chooses to develop from a snapshot of OFBiz, it is likely to miss out on
> constant improvements and may require a large “merge” effort eventually.
> If the effort chooses to be in sync with OFBiz constantly (like me),
> then local version control becomes very difficult.
>
>  
>
> Solution:
>
> The so-called distributed version control systems allow local
> repositories, local changes, and sync capabilities with the main
> repository. There are many such open-source products and I can help
> investigate the best option.
>
>  
>
> The catch:
>
> None of them have a “complete” Eclipse plugin or a GUI mode. DARCS has a
> very primitive eclipse plugin but not sure where that effort is headed.
>
>  
>
> Regards,
>
> Vinay Agarwal
>
>  
>
>
> ------------------------------------------------------------------------
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Vinay Agarwal]

David,

My personal "problem" with svn is that I can not "commit" my "local" changes
(that I do not want to share with OFBiz). I have tried unsuccessfully many
things to solve it and had a discussion on Users list titles "SVN
Replication." The solution the industry seems to believe is "distributed" or
"decentralized" version control systems.

If OFBiz were to use such system, I would be able to make a local repository
of OFBiz on my own server. My team members can checkout and commit changes
from/to this local repository at wish and get all the benefit of a version
control system. In order to update the local repository with OFBiz changes,
all I would need to do is execute "pull" command and changes would be
applied automatically. I can choose to "push" selected changes back to OFBiz
main repository (if I have write access). My team members can execute
"update" command on their machines and they will get OFBiz updates that are
available in the local repository. So, the benefits are
1. Proper source code management for a larger project
2. Team members' work is merged programmatically. With SVN, I have to
determine which files were changed by a team member and then copy them to a
common OFBiz working copy.
3. Central place to store all the changes to OFBiz main code base which can
be kept private for commercial applications.

Here's a quote from this link http://dwheeler.com/essays/scm.html

As you can tell, there seems to be two different schools of thought on how
SCM systems should work. Some people believe SCM systems should primarily
aid in controlling a centralized repository, and so they design their tool
to support a centralized repository (such as CVS and Subversion). Others
believe SCM systems should primarily aid in allowing independent developers
to work asynchronously, and then synchronize and pull in changes from each
others, so they develop tools to support a decentralized approach (like GNU
arch, monotone, darcs, Bazaar-NG, and Bitkeeper).

Here are some other links:

http://zooko.com/revision_control_quick_ref.html

http://better-scm.berlios.de/comparison/

Regards,
Vinay Agarwal

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of David E. Jones
Sent: Thursday, March 23, 2006 10:46 AM
To: OFBiz Project Development Discussion
Subject: Re: [OFBiz] Dev - Request to Use a Distributed Version Control
System When Code Base Changes


Vinay,

How is what these offer better than the SubVersion/SVN capabilities in this
area? We currently use SVN and plan to continue using it after the Apache
move.

-David


Vinay Agarwal wrote:

> Hello,
>
>  
>
> May I request to use a distributed version control system (monotone,
> DARCS, mercurial, bazaar-ng etc.) when the code base is switched over to
> Apache?
>
>  
>
> Problem:
>
> OFBiz is a fast changing project and expected to maintain its pace for
> the next year or so. A "significant" customization of OFBiz may require
> multiple engineers, significant development time, and need for
> maintaining local changes in a version control system. If such an effort
> chooses to develop from a snapshot of OFBiz, it is likely to miss out on
> constant improvements and may require a large "merge" effort eventually.
> If the effort chooses to be in sync with OFBiz constantly (like me),
> then local version control becomes very difficult.
>
>  
>
> Solution:
>
> The so-called distributed version control systems allow local
> repositories, local changes, and sync capabilities with the main
> repository. There are many such open-source products and I can help
> investigate the best option.
>
>  
>
> The catch:
>
> None of them have a "complete" Eclipse plugin or a GUI mode. DARCS has a
> very primitive eclipse plugin but not sure where that effort is headed.
>
>  
>
> Regards,
>
> Vinay Agarwal
>
>  
>
>
> ------------------------------------------------------------------------
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Adam Heath-2]

On Thu, 23 Mar 2006, Vinay Agarwal wrote:

> Hello,
>
>
>
> May I request to use a distributed version control system (monotone, DARCS,
> mercurial, bazaar-ng etc.) when the code base is switched over to Apache?

Apache uses svn.

I suggest svk, which is based on svn.

We've been using svk internally, and we have 15 repositories all linked from a
single ofbiz; I add new features or fixes to the single ofbiz branch, and then
automatically merge them into each of the 15.

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Vinay Agarwal]

Adam,

Would you like to share your procedure to create and maintain local
repositories with SVK? I have tried and failed.

Regards,
Vinay Agarwal

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Adam Heath
Sent: Thursday, March 23, 2006 11:22 AM
To: OFBiz Project Development Discussion
Subject: Re: [OFBiz] Dev - Request to Use a Distributed Version Control
System When Code Base Changes

On Thu, 23 Mar 2006, Vinay Agarwal wrote:

> Hello,
>
>
>
> May I request to use a distributed version control system (monotone,
DARCS,
> mercurial, bazaar-ng etc.) when the code base is switched over to Apache?

Apache uses svn.

I suggest svk, which is based on svn.

We've been using svk internally, and we have 15 repositories all linked from
a
single ofbiz; I add new features or fixes to the single ofbiz branch, and
then
automatically merge them into each of the 15.

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Andrew Sykes]

Vinay,

There's been a fair bit of discussion about how to handle this.

Discussion has generally focused around de-coupling your code from the
OFBiz code base using hot-deploy etc.

If you want to make minor changes you can maintain a few patch files, if
you want to make major changes, perhaps you need to write a new
application.
--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

Vinay,

You can do all of these things by setting up your own local SVN repository and using the vendor branch pattern for the OFBiz updates. This can do all of the merging and what not in an automated way (barring conflicts, which always have to be manually resolved regardless of the system).

Like Adam mentioned there are things built to work with SVN, like SVK, to make this easier to manage.

-David


Vinay Agarwal wrote:

> David,
>
> My personal "problem" with svn is that I can not "commit" my "local" changes
> (that I do not want to share with OFBiz). I have tried unsuccessfully many
> things to solve it and had a discussion on Users list titles "SVN
> Replication." The solution the industry seems to believe is "distributed" or
> "decentralized" version control systems.
>
> If OFBiz were to use such system, I would be able to make a local repository
> of OFBiz on my own server. My team members can checkout and commit changes
> from/to this local repository at wish and get all the benefit of a version
> control system. In order to update the local repository with OFBiz changes,
> all I would need to do is execute "pull" command and changes would be
> applied automatically. I can choose to "push" selected changes back to OFBiz
> main repository (if I have write access). My team members can execute
> "update" command on their machines and they will get OFBiz updates that are
> available in the local repository. So, the benefits are
> 1. Proper source code management for a larger project
> 2. Team members' work is merged programmatically. With SVN, I have to
> determine which files were changed by a team member and then copy them to a
> common OFBiz working copy.
> 3. Central place to store all the changes to OFBiz main code base which can
> be kept private for commercial applications.
>
> Here's a quote from this link http://dwheeler.com/essays/scm.html
>
> As you can tell, there seems to be two different schools of thought on how
> SCM systems should work. Some people believe SCM systems should primarily
> aid in controlling a centralized repository, and so they design their tool
> to support a centralized repository (such as CVS and Subversion). Others
> believe SCM systems should primarily aid in allowing independent developers
> to work asynchronously, and then synchronize and pull in changes from each
> others, so they develop tools to support a decentralized approach (like GNU
> arch, monotone, darcs, Bazaar-NG, and Bitkeeper).
>
> Here are some other links:
>
> http://zooko.com/revision_control_quick_ref.html
>
> http://better-scm.berlios.de/comparison/
>
> Regards,
> Vinay Agarwal
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of David E. Jones
> Sent: Thursday, March 23, 2006 10:46 AM
> To: OFBiz Project Development Discussion
> Subject: Re: [OFBiz] Dev - Request to Use a Distributed Version Control
> System When Code Base Changes
>
>
> Vinay,
>
> How is what these offer better than the SubVersion/SVN capabilities in this
> area? We currently use SVN and plan to continue using it after the Apache
> move.
>
> -David
>
>
> Vinay Agarwal wrote:
>> Hello,
>>
>>  
>>
>> May I request to use a distributed version control system (monotone,
>> DARCS, mercurial, bazaar-ng etc.) when the code base is switched over to
>> Apache?
>>
>>  
>>
>> Problem:
>>
>> OFBiz is a fast changing project and expected to maintain its pace for
>> the next year or so. A "significant" customization of OFBiz may require
>> multiple engineers, significant development time, and need for
>> maintaining local changes in a version control system. If such an effort
>> chooses to develop from a snapshot of OFBiz, it is likely to miss out on
>> constant improvements and may require a large "merge" effort eventually.
>> If the effort chooses to be in sync with OFBiz constantly (like me),
>> then local version control becomes very difficult.
>>
>>  
>>
>> Solution:
>>
>> The so-called distributed version control systems allow local
>> repositories, local changes, and sync capabilities with the main
>> repository. There are many such open-source products and I can help
>> investigate the best option.
>>
>>  
>>
>> The catch:
>>
>> None of them have a "complete" Eclipse plugin or a GUI mode. DARCS has a
>> very primitive eclipse plugin but not sure where that effort is headed.
>>
>>  
>>
>> Regards,
>>
>> Vinay Agarwal
>>
>>  
>>
>>
>> ------------------------------------------------------------------------
>>
>>  
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Vinay Agarwal]

Andrew,

I started with making changes in hot-deploy only and soon realized that it
was not possible for my application. It did not make sense to me to
replication say ecommerce application in hot-deploy if I only wanted to
change 1-2% of it. But that 1-2% is large enough along with 1-2% changes in
other applications, that I would want to maintain a proper code repository.

Regards,
Vinay Agarwal

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Andrew Sykes
Sent: Thursday, March 23, 2006 11:28 AM
To: OFBiz Project Development Discussion
Subject: Re: [OFBiz] Dev - Request to Use a Distributed VersionControl
System When Code Base Changes

Vinay,

There's been a fair bit of discussion about how to handle this.

Discussion has generally focused around de-coupling your code from the
OFBiz code base using hot-deploy etc.

If you want to make minor changes you can maintain a few patch files, if
you want to make major changes, perhaps you need to write a new
application.
--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Adam Heath-3]

On Thu, 23 Mar 2006, Vinay Agarwal wrote:

> Adam,
>
> Would you like to share your procedure to create and maintain local
> repositories with SVK? I have tried and failed.

The following script and instructions are based on several scripts we use
locally.  I created these scripts after much trial and error.  Most important
in this, was the ability to recreate everything from scratch, as I learned
each new step.

==
#!/bin/bash
# bash required, as we use local, which isn't posix
depot="externals"
internal_svn_host="svn-internal"
internal_username="[hidden email]"

die() {
        local result
        result=$1
        shift
        echo "$@" 1>&2
        exit $result
}

create_internal_job() {
        local client job
        client="$1"
        job="$2"
        shift 2 || die 1 "create_internal_job: incorrect parameter count"
        (
                cat << _VARS_
client="$client"
job="$job"
_VARS_
                cat << "_SCRIPT_"
set -x
rm -rf "/svn/$client-$job"
svnadmin create --fs-type bdb "/svn/$client-$job"
chmod -v g+ws $(find "/svn/$client-$job" -type d)
chmod -v g+w $(find "/svn/$client-$job" -type f)
ln -sf "../../.conf/passwd" "/svn/$client-$job/conf/passwd"
perl -pni.bak \
        -e 's/^\s*#.*\[general\].*/[general]/;' \
        -e 's/^\s*#\s*auth-access.*/auth-access = write/;' \
        -e 's/^\s*#\s*password-db.*/password-db = passwd/' \
        "/svn/$client-$job/conf/svnserve.conf"
_SCRIPT_
        ) | ssh "$internal_svn_host" /bin/sh -s
        rm -rf /tmp/svk.tmp
        svn co "svn://$internal_svn_host/$client-$job" /tmp/svk.tmp
        cd /tmp/svk.tmp
        mkdir trunk
        cd trunk
        mkdir ofbiz etc var components
        cd components
        mkdir "$job"
        cd "$job"
        mkdir config data entitydef lib script servicedef src webapp widget
        cd webapp
        mkdir "$job"
        cd "$job"
        mkdir WEB-INF
        cd ../../../../..
        svn add trunk
        svn ci --username "$username" -m "Initial paths"
        rm -rf /tmp/svk.tmp
        svk mirror "/$depot/repos/$client-$job" \
                "svn://$internal_svn_host/$client-$job/trunk"
        svk sync "/$depot/repos/$client-$job"
        svk cp -p -m "Branching for local development." \
                "/$depot/repos/$client-$job" \
                "/$depot/jobs/$client-$job"
        time svk smerge -BIl "/$depot/projects/ofbiz/trunk" \
                "/$depot/jobs/$client-$job/ofbiz"
        time svk smerge -Il "/$depot/jobs/$client-$job" \
                "/$depot/repos/$client-$job"
}

svk_init() {
        rm -rf "$HOME/.svk/$depot"
        svk depotmap "/$depot" "$HOME/.svk/$depot"
        rm -rf /tmp/svk.tmp
        svk co "/$depot/" /tmp/svk.tmp
        cd /tmp/svk.tmp
        mkdir -p projects/ofbiz repos
        cd projects/ofbiz
        mkdir features fixes branches tags
        cd ../..
        svk add *
        svk ci -m "Initial directories"
        svk mkdir /ofbiz/mirror
        svk mirror http://svn.ofbiz.org/svn/ofbiz \
                "/$depot/repos/ofbiz"
        # This next command will take a *long* time, while it
        # copies the entire ofbiz svn repository.
        svk sync "/$depot/repos/ofbiz"
        svk cp -m "Branching for local development." \
                "/$depot/repos/ofbiz" \
                "/$depot/projects/ofbiz/current"
        svk cp -m "Branching for internal trunk merging." \
                "/$depot/projects/ofbiz/current" \
                "/$depot/projects/ofbiz/trunk"
        svk cp -m "All fixes" \
                "/$depot/projects/ofbiz/current" \
                "/$depot/projects/ofbiz/fixes/all"
}

# you can pass -m "checkin message" to this as well.
create_new_fix() {
        local project fix
        project="$1"
        fix="$2"
        shift 2 || die 1 "create_new_fix: incorrect parameter count"
        svk cp -p "$@" \
                "/$depot/projects/$project/current" \
                "/$depot/projects/$project/fixes/$fix"
}

# you can pass -m "checkin message" to this as well.
create_new_feature() {
        local project feature
        project="$1"
        feature="$2"
        shift 2 || die 1 "create_new_feature: incorrect parameter count"
        svk cp -p "$@" \
                "/$depot/projects/$project/fixes/all" \
                "/$depot/projects/$project/features/$feature"
}

# you can pass -m "checkin message" to this as well.
merge_fix() {
        local project fix
        project="$1"
        fix="$2"
        shift 2 || die 1 "merge_fix: incorrect parameter count"
        svk smerge -Il "$@" \
                "/$depot/projects/$project/fixes/$fix" \
                "/$depot/projects/$project/fixes/all"
        svk smerge -Il "$@" \
                "/$depot/projects/$project/fixes/all" \
                "/$depot/projects/$project/trunk"
}

# you can pass -m "checkin message" to this as well.
merge_feature() {
        local project feature
        project="$1"
        feature="$2"
        shift 2 || die 1 "create_new_feature: incorrect parameter count"
        svk smerge -Il "$@" \
                "/$depot/projects/$project/features/$feature" \
                "/$depot/projects/$project/trunk"
}

==
. path/to/file/above
svk_init    # do this first time only, or when you want to start over
create_fix ofbiz fix-npe-in-random-code
svk co \
        "/$depot/projects/ofbiz/fixes/fix-npe-in-random-code" \
        "$HOME/work/ofbiz_fix_fix-npe-in-random-code"
cd "$HOME/work/ofbiz_fix_fix-npe-in-random-code"
# change files, fix one(and only one) bug, do several checkins if required.
merge_fix ofbiz fix-npe-in-random-code
# repeat above for features, too.
create_internal_job microsoft website
svk co \
        "svn://$internal_svn_host/microsoft-website/trunk" \
        "$HOME/work/microsoft-website"
cd "$HOME/work/microsoft-website"
# do work, do checkins, which get committed immediately back to svn-internal.
# to fetch new commits from other users who have committed to svn-internal, do
# either:
# svk sync "/$depot/repos/$client-$job"
# svk up "$HOME/work/microsoft-website"
# or
# svk pull "$HOME/work/microsoft-website"

# merge all fixes and whatever features into client-job
svk smerge -Il \
        "/$depot/projects/ofbiz/trunk" \
        "/$depot/repos/microsoft-website"
==
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Vinay Agarwal]

David,
Thanks for this info. Perhaps vendor branch will do everything I want. I am
working on it right now.
Regards,
Vinay

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of David E. Jones
Sent: Thursday, March 23, 2006 11:30 AM
To: OFBiz Project Development Discussion
Subject: Re: [OFBiz] Dev - Request to Use a Distributed Version Control
System When Code Base Changes


Vinay,

You can do all of these things by setting up your own local SVN repository
and using the vendor branch pattern for the OFBiz updates. This can do all
of the merging and what not in an automated way (barring conflicts, which
always have to be manually resolved regardless of the system).

Like Adam mentioned there are things built to work with SVN, like SVK, to
make this easier to manage.

-David


Vinay Agarwal wrote:
> David,
>
> My personal "problem" with svn is that I can not "commit" my "local"
changes
> (that I do not want to share with OFBiz). I have tried unsuccessfully many
> things to solve it and had a discussion on Users list titles "SVN
> Replication." The solution the industry seems to believe is "distributed"
or
> "decentralized" version control systems.
>
> If OFBiz were to use such system, I would be able to make a local
repository
> of OFBiz on my own server. My team members can checkout and commit changes
> from/to this local repository at wish and get all the benefit of a version
> control system. In order to update the local repository with OFBiz
changes,
> all I would need to do is execute "pull" command and changes would be
> applied automatically. I can choose to "push" selected changes back to
OFBiz
> main repository (if I have write access). My team members can execute
> "update" command on their machines and they will get OFBiz updates that
are
> available in the local repository. So, the benefits are
> 1. Proper source code management for a larger project
> 2. Team members' work is merged programmatically. With SVN, I have to
> determine which files were changed by a team member and then copy them to
a
> common OFBiz working copy.
> 3. Central place to store all the changes to OFBiz main code base which
can
> be kept private for commercial applications.
>
> Here's a quote from this link http://dwheeler.com/essays/scm.html
>
> As you can tell, there seems to be two different schools of thought on how
> SCM systems should work. Some people believe SCM systems should primarily
> aid in controlling a centralized repository, and so they design their tool
> to support a centralized repository (such as CVS and Subversion). Others
> believe SCM systems should primarily aid in allowing independent
developers
> to work asynchronously, and then synchronize and pull in changes from each
> others, so they develop tools to support a decentralized approach (like
GNU

> arch, monotone, darcs, Bazaar-NG, and Bitkeeper).
>
> Here are some other links:
>
> http://zooko.com/revision_control_quick_ref.html
>
> http://better-scm.berlios.de/comparison/
>
> Regards,
> Vinay Agarwal
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of David E. Jones
> Sent: Thursday, March 23, 2006 10:46 AM
> To: OFBiz Project Development Discussion
> Subject: Re: [OFBiz] Dev - Request to Use a Distributed Version Control
> System When Code Base Changes
>
>
> Vinay,
>
> How is what these offer better than the SubVersion/SVN capabilities in

this

> area? We currently use SVN and plan to continue using it after the Apache
> move.
>
> -David
>
>
> Vinay Agarwal wrote:
>> Hello,
>>
>>  
>>
>> May I request to use a distributed version control system (monotone,
>> DARCS, mercurial, bazaar-ng etc.) when the code base is switched over to
>> Apache?
>>
>>  
>>
>> Problem:
>>
>> OFBiz is a fast changing project and expected to maintain its pace for
>> the next year or so. A "significant" customization of OFBiz may require
>> multiple engineers, significant development time, and need for
>> maintaining local changes in a version control system. If such an effort
>> chooses to develop from a snapshot of OFBiz, it is likely to miss out on
>> constant improvements and may require a large "merge" effort eventually.
>> If the effort chooses to be in sync with OFBiz constantly (like me),
>> then local version control becomes very difficult.
>>
>>  
>>
>> Solution:
>>
>> The so-called distributed version control systems allow local
>> repositories, local changes, and sync capabilities with the main
>> repository. There are many such open-source products and I can help
>> investigate the best option.
>>
>>  
>>
>> The catch:
>>
>> None of them have a "complete" Eclipse plugin or a GUI mode. DARCS has a
>> very primitive eclipse plugin but not sure where that effort is headed.
>>
>>  
>>
>> Regards,
>>
>> Vinay Agarwal
>>
>>  
>>
>>
>> ------------------------------------------------------------------------
>>
>>  
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Vinay Agarwal]

Hello,

I found out how to use SVK for creating local SVN repositories. (Adam thanks
for the scripts but I didn't spend time on them). I think this method is
easier than vendor branch. I created a Wiki page which is copied below.

Regards,
Vinay Agarwal

Creating SVN Mirror Repository Using SVK

This is an alternative to, and hopefully easier than, "vendor branch" method
for source code management. This method takes a few minutes to complete
updates and is fully automated except for conflicts. This description does
not include trunk/branches for simplicity.

1. Install SVK.
2. Create a local SVN (or SVK) repository in your PC/LAN using regular svn
command.
3. Tell SVK about this repository. SVK calls it depot.

    svk depotmap

    An editor will pop-up (which can be changed using $EDITOR environment
variable). Edit it to point to your repository and save.

4. Create a mirror of http://svn.ofbiz.org/svn/ofbiz/trunk in your local
PC/LAN. We will call it uplink.

    svk mirror http://svn.ofbiz.org/svn/ofbiz/trunk //uplink

    svk sync //uplink

    sync operation takes about 3 hours on my system and must be restarted
several times in order to complete.

    DANGER: Make sure //uplink is never used with any SVN command or it will
corrupt the mirror capability. You may make a backup of this by using

    svk copy //uplink //uplinkbackup

5. Create a working repository for SVN users (it uses the same copy command)

    svk copy //uplink //local

    //local is now the SVN local repository.

Usage
1. Checkout using SVN (not SVK) from //local
2. Make changes as usual
3. Use regular svn client commands (e.g. commit, update) for code management
which now talk to //local repository
4. To download updates from OFBiz

    svk sync //uplink

5. To merge changes to local repository

    svk smerge //uplink //local

6. To update working copies, use svn update command.
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev