You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by John <js...@ecclescollege.ac.uk> on 2005/07/09 15:44:58 UTC
Usage advice - personal branches
I've been using SVN for about 12 months now, but I'd like some advice for
laying out busy, multi user repositories.
We have a policy of committing often (as savepoints, in case of source code
corruption - we use MS Visual Studio....!). This means that 70% or more of
revisions don't leave trunk in a 'good' state, and work is only partially
finished. Obviously this is a pain.
What I'm planning is to have a branch inside each project, for each
person working on the system. ie:
AmazingProject1
-trunk
-branches
--John
--Peter
--Jane
During normal work developers only commit to their branch (hence no problem
with 'savepoint' commits). When a feature is fully implemented it is merged
into trunk (and also trunk changes are merged into the personal branch).
Is this the best option? Or should I look at some form of distributed
version control system? In some ways I'd like my working copy to belong to
two seperate repo's: a personal, local one for regular savepoints, and a
central one for sharing.
Thanks,
John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Usage advice - personal branches
Posted by Tom Opgenorth <op...@gmail.com>.
> This is fine, if you don't care about log history. Every time you
> branch a file and then merge it back, any log history on trunk version
> of file between branch and merge, will be lost. Thus, there will be
> changes made to the file, that won't be documented on the version of
> the file that sits at trunk head.
Just thinking outloud here. If one is interested in preserving the
log history between the personal branch and the main, could you not
just "merge" outside of SVN, from the personal branch to the trunk and
then commit the trunk?
For example: I make my personal branch and work in that for a while.
When I want to put my personal branch into the trunk, I use something
like Araxis Merge/WinMerge/KDiff three and merge my changes from my
personal branch to the trunk. Then I do a commit on the trunk.
Sounds kind of convoluted, but I guess it allows you to keep your log
history on the trunk, does it no?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Usage advice - personal branches
Posted by Saulius Grazulis <gr...@akl.lt>.
On Saturday 09 July 2005 19:58, Quest wrote:
> > Is this the best option? Or should I look at some form of distributed
> > version control system? In some ways I'd like my working copy to belong
> > to two seperate repo's: a personal, local one for regular savepoints, and
> > a central one for sharing.
>
> This sounds more like arch to me.
Or maybe SVK?
--
Saulius Gražulis
Visuomeninė organizacija "Atviras Kodas Lietuvai"
P.Vileišio g. 18
LT-10306 Vilnius
Lietuva (Lithuania)
tel/fax: (+370-5)-210 40 05
mobilus: (+370-684)-49802, (+370-614)-36366
Re: Usage advice - personal branches
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
On Saturday 09 July 2005 22:21, Joshua Varner wrote:
> If the goal is simply to create save points to avoid corruption you
> might try writing a script that saves an svn-diff of your working copy
> to a safe location, and then if something corrupts your working copy,
> you can svn revert (or recheck out the directory) and apply the diff
> file. If you want these versioned you can create a separate repository
> to hold these, that would avoid creating extraneous commits in the
> main repository, real check points would be checked into branches as
> normal, it would be only these anti-corruption diffs that would never
> go into the repository.
Just for savepoints - how about
svn cp . URL/branches/John/save/`date`
or something like that? Should be space-efficient, as most files aren't
changed.
Maybe even a merge of your local changes into another branch ...
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Usage advice - personal branches
Posted by Joshua Varner <jl...@gmail.com>.
On 7/9/05, John <js...@ecclescollege.ac.uk> wrote:
> Quest <quest <at> lysator.liu.se> writes:
>
> > > In some ways I'd like my working copy to belong to
> > > two seperate repo's: a personal, local one for regular savepoints, and a
> > > central one for sharing.
> >
> > This sounds more like arch to me.
>
> I don't suppose it would be wise to keep two copies of .svn in the working
> directory would it, and do:
>
> move .svn .localsvn
> move .centralsvn .svn
> svn commit
> move .svn .centralsvn
> move .localsvn .svn
>
> (assuming .cenralsvn and .localsvn are in the ignore list).
>
> That's so crazy it might work.... ;)
>
I've done this with CVS before, but never tried with svn since it
handles vendor branches well. I had a make target that would switch
which repository's files were in the CVS directory.
Then I version controlled the external projects CVS files, with svn
that would be more problematic since it stores text-base and such.
This would have the side effect of making your working copy take up 3
times the space of the files contained.
If the goal is simply to create save points to avoid corruption you
might try writing a script that saves an svn-diff of your working copy
to a safe location, and then if something corrupts your working copy,
you can svn revert (or recheck out the directory) and apply the diff
file. If you want these versioned you can create a separate repository
to hold these, that would avoid creating extraneous commits in the
main repository, real check points would be checked into branches as
normal, it would be only these anti-corruption diffs that would never
go into the repository.
Or you could look at svk - it is a subversion based distributed system.
Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Usage advice - personal branches
Posted by John <js...@ecclescollege.ac.uk>.
Quest <quest <at> lysator.liu.se> writes:
> > In some ways I'd like my working copy to belong to
> > two seperate repo's: a personal, local one for regular savepoints, and a
> > central one for sharing.
>
> This sounds more like arch to me.
I don't suppose it would be wise to keep two copies of .svn in the working
directory would it, and do:
move .svn .localsvn
move .centralsvn .svn
svn commit
move .svn .centralsvn
move .localsvn .svn
(assuming .cenralsvn and .localsvn are in the ignore list).
That's so crazy it might work.... ;)
John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Usage advice - personal branches
Posted by Quest <qu...@lysator.liu.se>.
On Sat, 9 Jul 2005 15:44:58 +0000 (UTC), John <js...@ecclescollege.ac.uk> writes:
> I've been using SVN for about 12 months now, but I'd like some advice for
> laying out busy, multi user repositories.
>
> We have a policy of committing often (as savepoints, in case of source code
> corruption - we use MS Visual Studio....!). This means that 70% or more of
> revisions don't leave trunk in a 'good' state, and work is only partially
> finished. Obviously this is a pain.
>
> What I'm planning is to have a branch inside each project, for each
> person working on the system. ie:
>
> AmazingProject1
> -trunk
> -branches
> --John
> --Peter
> --Jane
>
> During normal work developers only commit to their branch (hence no problem
> with 'savepoint' commits). When a feature is fully implemented it is merged
> into trunk (and also trunk changes are merged into the personal branch).
This is fine, if you don't care about log history. Every time you
branch a file and then merge it back, any log history on trunk version
of file between branch and merge, will be lost. Thus, there will be
changes made to the file, that won't be documented on the version of
the file that sits at trunk head.
So, if you usually branch to change different parts of the code and
don't make updates on trunk, everything's fine. Or, if you don't care
about logs :).
> Is this the best option? Or should I look at some form of distributed
> version control system? In some ways I'd like my working copy to belong to
> two seperate repo's: a personal, local one for regular savepoints, and a
> central one for sharing.
This sounds more like arch to me.
--
Anders "Quest" Qvist
Ye olde jungle proverb:
Even the Phantom must turn on the light to see what's in his goth wardrobe.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org