By the way, here is what we're doing with our SVN repositories. This
is part of a larger document which I'll hopefully find time to put
online soon:
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] [[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] [[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
Locked
