Tagging changesets

[John Doisneau <jd...@gmail.com>]

Hello

I have a question that I have been wanting for quite a long time - I
hope I will write it clearly enough.

In our company, we are eager to switch to SubVersion (we did not have
any version control until now) but there could be one functionality
that we would lose if it is not supported: the possibility of tagging
changesets.

By "changeset" I mean a set of changes made in various files of the
software project all relative to the same evolution or correction.

Let's consider the following situation: today I worked out the 2
following changesets:
- To implement FunctionalityA, I had to change (or add) code in files
File1, File5 and File102
- To correct BugB (which is in no way related to FunctionalityA except
it shares some of its files), I had to modify File1 and File102

Let's say that I organized my day such that I worked the first couple
hours of the day on FunctionalityA, then I switched to BugB until the
middle of the afternoon, and then I went back to FunctionalityA, such
that at the end of the day I have completed those 2 tasks - ie my
changesets are ready to be commited to the SVN repository.

Now I would like to commit my code in such a way that it is possible
later for somebody to quickly see and take all the changes made to
implement FunctionalityA, and separately to correct BugB. How do I
perform this commit action?

If the changesets were not having some files in common, I could easily
commit in two steps:
1) commit the files of FunctionalityA
2) commit the files of BugB

Now you see that my problem is that the two changesets have some files
in common, so what can I do there? I cannot select part of a file and
commit just that part under TAG_FCT_A or TAG_BUG_B.

Would somebody have a suggestion to keep our organization in separate
changesets?

Thanks in advance!

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

Re: Tagging changesets

[eg <eg...@gmail.com>]

John Doisneau wrote:
> 
> Let's consider the following situation: today I worked out the 2
> following changesets:
> - To implement FunctionalityA, I had to change (or add) code in files
> File1, File5 and File102
> - To correct BugB (which is in no way related to FunctionalityA except
> it shares some of its files), I had to modify File1 and File102
> 

If they use the same files in the same directory, how can you expect to 
"identify" which set of line changes corresponds to which "changeset"?

In the end, if you want to treat them as separate logically related 
changes they need to be committed as such. If you wish, you can set up a 
branch on which to perform one of the changesets, and then merge it back 
in when ready. Branching is fast and easy.

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

Re: Tagging changesets

[Les Mikesell <le...@gmail.com>]

On 8/23/06, John Doisneau <jd...@gmail.com> wrote:
>
> In our company, we are eager to switch to SubVersion (we did not have
> any version control until now) but there could be one functionality
> that we would lose if it is not supported: the possibility of tagging
> changesets.

Can you explain how you manage this now?  That is, what functionality
you have that you might lose?

> Let's say that I organized my day such that I worked the first couple
> hours of the day on FunctionalityA, then I switched to BugB until the
> middle of the afternoon, and then I went back to FunctionalityA, such
> that at the end of the day I have completed those 2 tasks - ie my
> changesets are ready to be commited to the SVN repository.
>
> Now I would like to commit my code in such a way that it is possible
> later for somebody to quickly see and take all the changes made to
> implement FunctionalityA, and separately to correct BugB. How do I
> perform this commit action?

Commit often.  You might commit this in 4 steps, depending on how
the work went.  So you'd have 2 parts where the commit message
mentions work on FunctionalityA and 2 that mention BugB.

> Now you see that my problem is that the two changesets have some files
> in common, so what can I do there? I cannot select part of a file and
> commit just that part under TAG_FCT_A or TAG_BUG_B.

I don't understand how you'd do that without version control either.
But, there's
no reason to wait till the end of the day to commit - or until you
have completed
some number of changes.  Commit with whatever granularity you want.

-- 
  Les Mikesell
   lesmikesell@gmail.com

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

Re: Tagging changesets

["Daniele P." <da...@interline.it>]

On Wednesday 23 August 2006 19:01, John Doisneau wrote:
> Hello
>
> I have a question that I have been wanting for quite a long time - I
> hope I will write it clearly enough.

Hello John.
I hope to do the same. (I'm new to the list)

[...]

> Let's say that I organized my day such that I worked the first couple
> hours of the day on FunctionalityA, then I switched to BugB until the
> middle of the afternoon, and then I went back to FunctionalityA, such
> that at the end of the day I have completed those 2 tasks - ie my
> changesets are ready to be commited to the SVN repository.

You shouldn't. IMHO it's better to done one thing right.
You could also create two branches and then merge them. But it could
be an overkill, or the right thing to do, depending on your policies.

> Now I would like to commit my code in such a way that it is possible
> later for somebody to quickly see and take all the changes made to
> implement FunctionalityA, and separately to correct BugB. How do I
> perform this commit action?
>
> If the changesets were not having some files in common, I could easily
> commit in two steps:
> 1) commit the files of FunctionalityA
> 2) commit the files of BugB

Right.

> Now you see that my problem is that the two changesets have some files
> in common, so what can I do there? I cannot select part of a file and
> commit just that part under TAG_FCT_A or TAG_BUG_B.

AFAIK no. 
I know that darcs, mercurial and svk have this feature (in svk is a new 
feature, no so stable)

> Would somebody have a suggestion to keep our organization in separate
> changesets?

Simply start doing one thing right. 

Daniele P.

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

Re: Tagging changesets

[Talden <ta...@gmail.com>]

Then I guess you do need to do the work on a branch and once final and
committed merge back to trunk, delete branch, commit and record that
revision number as the changeset - certainly adds some 'noise' to the
log.

It means dealing with merging, which, if a once off is fine, if not it
seems the best option is playing with a .py script.  I'm guessing that
merge-tracking is a way off given it's dependant upon an atomic move
operation amongst many other complicated tasks.

--
Talden

On 8/24/06, Gavin Lambert <ga...@compacsort.com> wrote:
> Quoth Talden <ma...@gmail.com>:
> > These are hopefully valid assumptions
> > - The Commit command accepts a 'list file' of paths to commit.
> > - Each commit is atomic and all changes are identifiable by
> > the resulting revision number
> > - You can list all changes made between a given revision
> > number and its predecessor.
> >
> > If those are true then creating two 'list files' that
> > respectively include the modifications for each of the
> > changes would allow you to commit them separately with
> > meaningful commit messages and then update your issue tracker
> > with the resulting revision numbers.
>
> Only if there are no overlapping files in those two lists.  If there's
> an overlap then the first commit will commit all changes to the file,
> since it's impossible to separate them at that point (unless they've
> been developed in isolation, on separate branches).
>
>

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

Re: Tagging changesets

[Peter Werner <l....@vasas.no-ip.org>]

> 2) Before  "committing" our changes (it is not really a commit since
> we are not using version control software but it is equivalent) we use
> a "differencing" software like Beyond Compare: it shows all the
> changes made for both tasks and allows in place editing - we then use
> the in place editing feature to add a little tag written like a
> comment like /* FCT_A */ or /* BUG_B*/ at each block of code which was
> added or modified. And usually at the top of the file where the most
> changes have been made we add a longer description of the feature,
> like
> /* FCT_A: Developer DDD - mm/dd/yy - Implemented functionality A */

It is possible to do the same with svn (or any other tool).  If I make
this _mistake_ to mix up several changes I do the following:

svn diff file1 > patch1
cp patch1 patch2
cp file1 file1.backup
svn revert file1
edit patch1 patch2 to separate the differences
patch < patch1
svn commit -m 'function A'
patch < patch2
# sure is sure: diff file1 file1.backup
svn commit -m 'bugfix B'

It can be a bit more complex with several files but not really hard in
practice.  It worth the effort to have nice small separated commits.

It's equivalent to your old way.  Both have the risk that you mix up
your changesets.  Separating changesets is unnecessary work, you should
do something smarter.

1. You can maintain two local copies, one for normal development, the
other for smaller high priority changes that can interrupt your normal
work.

2. You also can save your current changes, revert, do the bugfix,
restore your previous files. (patch is your friend)

3. You can create a branch, commit your changes there.  Switch to trunk,
do the bugfix, switch back to the branch, finish your change, merge to
trunk.

  WP

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

Re: Tagging changesets

[John Doisneau <jd...@gmail.com>]

Thank you all for your replies.

I guess that the "2 working copies" scheme is the way to go, but is
this really practical when the software project is really big? Our
software contains about 3000 files. What do you think about your
solution in this case?

To answer the question "How are we currently doing this today in my
company?", we are doing it using a very simple method:

1) Work on FunctionalityA and BugB in the order you want, switching
from one task to the other as you wish

2) Before  "committing" our changes (it is not really a commit since
we are not using version control software but it is equivalent) we use
a "differencing" software like Beyond Compare: it shows all the
changes made for both tasks and allows in place editing - we then use
the in place editing feature to add a little tag written like a
comment like /* FCT_A */ or /* BUG_B*/ at each block of code which was
added or modified. And usually at the top of the file where the most
changes have been made we add a longer description of the feature,
like
/* FCT_A: Developer DDD - mm/dd/yy - Implemented functionality A */

Does that make sense? Does that bring more comments?
Thanks.

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

Re: Tagging changesets

[Alan Barrett <ap...@cequrux.com>]

On Thu, 24 Aug 2006, Gavin Lambert wrote:
> Only if there are no overlapping files in those two lists.  If there's
> an overlap then the first commit will commit all changes to the file,
> since it's impossible to separate them at that point (unless they've
> been developed in isolation, on separate branches).

If you are working on two separate issues (say a bug fix and a new
feature), you can use a single branch (say the trunk) and two separate
working copies.  Having one developer with two working copies is very
very similar to having two developers with one working copy each.

--apb (Alan Barrett)

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

RE: Tagging changesets

[Gavin Lambert <ga...@compacsort.com>]

Quoth Talden <ma...@gmail.com>:
> These are hopefully valid assumptions
> - The Commit command accepts a 'list file' of paths to commit.
> - Each commit is atomic and all changes are identifiable by
> the resulting revision number
> - You can list all changes made between a given revision
> number and its predecessor.
> 
> If those are true then creating two 'list files' that
> respectively include the modifications for each of the
> changes would allow you to commit them separately with
> meaningful commit messages and then update your issue tracker
> with the resulting revision numbers.

Only if there are no overlapping files in those two lists.  If there's
an overlap then the first commit will commit all changes to the file,
since it's impossible to separate them at that point (unless they've
been developed in isolation, on separate branches).

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

Re: Tagging changesets

[Talden <ta...@gmail.com>]

Considering I'm very new to Subversion as well (still evaluating it
for my workplace in fact) hopefully this understanding isn't too far
'out there'.

These are hopefully valid assumptions
- The Commit command accepts a 'list file' of paths to commit.
- Each commit is atomic and all changes are identifiable by the
resulting revision number
- You can list all changes made between a given revision number and
its predecessor.

If those are true then creating two 'list files' that respectively
include the modifications for each of the changes would allow you to
commit them separately with meaningful commit messages and then update
your issue tracker with the resulting revision numbers.

You can even paste the contents of the commit list to the issue
tracker as a record.

(on a separate note and clearly not one this list should be expected
to answer but...)
Why doesn't RapidSVN do exactly this to support atomic commits across
folders - since one of the big advantages of SVN is atomic commits
that seems a sensible approach.

--
Talden

On 8/24/06, John Doisneau <jd...@gmail.com> wrote:
> Hello
>
> I have a question that I have been wanting for quite a long time - I
> hope I will write it clearly enough.
>
> In our company, we are eager to switch to SubVersion (we did not have
> any version control until now) but there could be one functionality
> that we would lose if it is not supported: the possibility of tagging
> changesets.
>
> By "changeset" I mean a set of changes made in various files of the
> software project all relative to the same evolution or correction.
>
> Let's consider the following situation: today I worked out the 2
> following changesets:
> - To implement FunctionalityA, I had to change (or add) code in files
> File1, File5 and File102
> - To correct BugB (which is in no way related to FunctionalityA except
> it shares some of its files), I had to modify File1 and File102
>
> Let's say that I organized my day such that I worked the first couple
> hours of the day on FunctionalityA, then I switched to BugB until the
> middle of the afternoon, and then I went back to FunctionalityA, such
> that at the end of the day I have completed those 2 tasks - ie my
> changesets are ready to be commited to the SVN repository.
>
> Now I would like to commit my code in such a way that it is possible
> later for somebody to quickly see and take all the changes made to
> implement FunctionalityA, and separately to correct BugB. How do I
> perform this commit action?
>
> If the changesets were not having some files in common, I could easily
> commit in two steps:
> 1) commit the files of FunctionalityA
> 2) commit the files of BugB
>
> Now you see that my problem is that the two changesets have some files
> in common, so what can I do there? I cannot select part of a file and
> commit just that part under TAG_FCT_A or TAG_BUG_B.
>
> Would somebody have a suggestion to keep our organization in separate
> changesets?
>
> Thanks in advance!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>

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