keeping track of branch creation point

[Timothee Besset <tt...@idsoftware.com>]

I'm putting together an svn server using vendor branch extensively. One
thing I noticed, if I use svn cp to create a branch, there is no easy way
to recall the branch at the state when it was created. I would have to do
another svn cp as a 'tag' right after creating the branch.

If you don't svn tag your new branch right after creation, you have to svn
log it and find out what revision number to use as the start point. Not
sure wether or not there should be a command or a revision syntax to point
to the 'branch creation' revision.

Another thing I'm seeing, is that the concept of branches versus tags in
svn is very artificial. I think we like to talk about branches and tags
because we've spent too many years working with cvs. Since svn doesn't
make any difference between branches and tags, it's all up to users
discipline in considering that 'tags' are not meant to be modified and
evolve, whereas branches do evolve.

In that regard, I think it would make sense if the location in repository
where the admins decide to store tags would be only available to branch
creation and removal, but not 'modifications'. This is strictly to enforce
a difference between the tag and branch concepts, and to be safe from
wrong manipulations.

TTimo

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: repeated merges

[Karl Fogel <kf...@newton.ch.collab.net>]

Timothee Besset <tt...@idsoftware.com> writes:
> I am adapting a script I wrote to do vendor branches with repeated merges
> in a semi-automated way to svn, so for now I handle the repeated merges
> and revision number housekeeping from my scripts. The problem I've hit is
> on the first merge, where I don't have rev1 to provide in "svn merge
> -rrev1:rev2". I would love to have something that can tell "this branch
> started at rev rev1". Or even give it rev 0 and mean that this means "the
> first time this file appeared".

Well, we don't need to special case rev 0.  We could just use a new
revision keyword, "ORIG", analogous to "BASE", "HEAD", etc.

Hmmm, Bill Tutt, is this related to your "[PATCH] Fix for 1003"?  That
is, is this a feature that gets easier or more efficient to implement
once your patch is in?

-K


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: repeated merges

[Ben Collins-Sussman <su...@collab.net>]

Timothee Besset <tt...@idsoftware.com> writes:

> What I'm trying to say, is that maybe svn cp should create a property or
> something on the directory when the branch is created? Anything that would
> allow easy retrieval of the point where the branch was created, instead of
> having to read svn log?

Yes, it's generally agreed that this is exactly the first step in
solving the repeated merge problem.  Nobody's bothered to do this yet,
because nobody's exactly sure how they want to design the properties
that hold this data.  (The data will eventually be a lot more complex
than just this first branch-creation step.)



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: repeated merges

[Ben Collins-Sussman <su...@collab.net>]

Timothee Besset <tt...@idsoftware.com> writes:

> I am adapting a script I wrote to do vendor branches with repeated merges
> in a semi-automated way to svn, so for now I handle the repeated merges
> and revision number housekeeping from my scripts. The problem I've hit is
> on the first merge, where I don't have rev1 to provide in "svn merge
> -rrev1:rev2". I would love to have something that can tell "this branch
> started at rev rev1". Or even give it rev 0 and mean that this means "the
> first time this file appeared".

So why not set a custom property on the directory, rather than create
a whole new tag?


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: repeated merges

[Timothee Besset <tt...@idsoftware.com>]

On 24 Nov 2002 08:12:21 -0600
Ben Collins-Sussman <su...@collab.net> wrote:

> Timothee Besset <tt...@idsoftware.com> writes:
> 
> > If you don't svn tag your new branch right after creation, you have to svn
> > log it and find out what revision number to use as the start point. Not
> > sure wether or not there should be a command or a revision syntax to point
> > to the 'branch creation' revision.
> 
> Yup.  That's why we need to solve the "repeated merge" problem
> someday.  Humans shouldn't have to remember the exact revision in
> which a branch was created, or remember exactly which revisions have
> been merged from one branch to another.  Someday Subversion will
> automate that knowledge for you, probably by tracking the info in
> properties.
> 

Yep, I know repeated merges are planned post 1.0

I am adapting a script I wrote to do vendor branches with repeated merges
in a semi-automated way to svn, so for now I handle the repeated merges
and revision number housekeeping from my scripts. The problem I've hit is
on the first merge, where I don't have rev1 to provide in "svn merge
-rrev1:rev2". I would love to have something that can tell "this branch
started at rev rev1". Or even give it rev 0 and mean that this means "the
first time this file appeared".

TTimo

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: keeping track of branch creation point

[Ben Collins-Sussman <su...@collab.net>]

Sebastien Cevey <se...@cine7.net> writes:

> On Sun, Nov 24, 2002 at 08:12:21AM -0600, Ben Collins-Sussman wrote:
> 
> > Humans shouldn't have to remember the exact revision in which a
> > branch was created
> 
> Isn't there a way to remember when (=which revision) a file/directory
> was added to the repository ? Something like "First Changed Revision"
> just like the "Last Changed Revision" given by svn info ?

Run 'svn log' on the object and see what last printed rev is.  :-)

Really, that's just the same as running svn_fs_revisions_changed() on
an object.  I suppose the server could send this "first revision" to
the client to be cached, just like "last changed revision" is cached,
and we could map a revision keyword to it, like FIRST.  But I'm not
sure how often it would be used.  The very first time you do a merge
from branch to branch, you'd use the FIRST value.  The next time you
do a merge, you'd continue merging from whatever revision you left off
at.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: keeping track of branch creation point

[Sebastien Cevey <se...@cine7.net>]

On Sun, Nov 24, 2002 at 08:12:21AM -0600, Ben Collins-Sussman wrote:

> Humans shouldn't have to remember the exact revision in which a
> branch was created

Isn't there a way to remember when (=which revision) a file/directory
was added to the repository ? Something like "First Changed Revision"
just like the "Last Changed Revision" given by svn info ?

-- 
Sebastien Cevey <se...@cine7.net>
Cine7 - www.cine7.net
Milcis - www.milcis.net
ICQ: 48895760

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: keeping track of branch creation point

[Ben Collins-Sussman <su...@collab.net>]

Timothee Besset <tt...@idsoftware.com> writes:

> If you don't svn tag your new branch right after creation, you have to svn
> log it and find out what revision number to use as the start point. Not
> sure wether or not there should be a command or a revision syntax to point
> to the 'branch creation' revision.

Yup.  That's why we need to solve the "repeated merge" problem
someday.  Humans shouldn't have to remember the exact revision in
which a branch was created, or remember exactly which revisions have
been merged from one branch to another.  Someday Subversion will
automate that knowledge for you, probably by tracking the info in
properties.

> Another thing I'm seeing, is that the concept of branches versus tags in
> svn is very artificial. I think we like to talk about branches and tags
> because we've spent too many years working with cvs.

Well, the terms "branch" and "tag" are universal SCM terms.  They're
not unique to cvs.  They're general concepts that are still useful to
everyone.  Subversion just happens to implement both concepts through
copying.

> In that regard, I think it would make sense if the location in repository
> where the admins decide to store tags would be only available to branch
> creation and removal, but not 'modifications'. This is strictly to enforce
> a difference between the tag and branch concepts, and to be safe from
> wrong manipulations.

Um, yup.  That's exactly what the svn Book has always said.  If admins
don't trust users to remember to treat a tag directory like a tag,
then they can use an access-control script to only allow "cp" and "rm"
within the /tags area.  As Rafael mentioned, we have both a perl and
python script for fine-grained access control.

But let me remind you of something:  if somebody *does* accidentally
commit a change to a tag directory, who cares?  Just undo it, and
scold the user.  This is version control.  :-)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: keeping track of branch creation point

[Rafael Garcia-Suarez <rg...@wanadoo.fr>]

Timothee Besset wrote:
> In that regard, I think it would make sense if the location in repository
> where the admins decide to store tags would be only available to branch
> creation and removal, but not 'modifications'. This is strictly to enforce
> a difference between the tag and branch concepts, and to be safe from
> wrong manipulations.

In fact, what you want is to forbid modifications to files and directories
under /tags/*/ or something like that ? This sounds like a job for a
hook script. In fact, I think that commit-access-control.pl (in the
/tools/hook-scripts directory) can help you.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org