Re: sync repositories

[Paul Sander]

>--- Forwarded mail from [EMAIL PROTECTED]

>On Fri, Aug 09, 2002 at 12:50:06PM -0700, Paul Sander wrote:
>> Each site owns its own trunk.  Each site creates a branch that is used for
>> importing from the other site(s); these branches map to the trunk(s) at the
>> remote site(s).  No local commits are permitted on the import branches.
>> Each site keeps a list of branches to export to the other site(s), and
>> tracks the latest exported versions on each export branch.

>Interesting approach.  With some scripting, it could actually
>work...

Of course it will work.  You have no faith!  ;-)

>Geez, it sounds like a CVS-based (partial) implementation of your
>old EMFS thingie :-)

This design is way better than EMFS, actually.  It keeps the original
changes at each site on separate branches, so they're easier track and
isolate if necessary.  EMFS allows the definitive sources to get out of
synch with the remote copies, which can't happen with a versioning system
(provided the branch mastership conventions are enforced strictly).

>--- End of forwarded message from [EMAIL PROTECTED]


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: sync repositories

[Eric Siegerman]

On Fri, Aug 09, 2002 at 12:50:06PM -0700, Paul Sander wrote:
> Each site owns its own trunk.  Each site creates a branch that is used for
> importing from the other site(s); these branches map to the trunk(s) at the
> remote site(s).  No local commits are permitted on the import branches.
> Each site keeps a list of branches to export to the other site(s), and
> tracks the latest exported versions on each export branch.

Interesting approach.  With some scripting, it could actually
work...

Geez, it sounds like a CVS-based (partial) implementation of your
old EMFS thingie :-)

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|  |  /
Anyone who swims with the current will reach the big music steamship;
whoever swims against the current will perhaps reach the source.
- Paul Schneider-Esleben

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: sync repositories

[Mike Ayers]

Zieg, Mark wrote:
>>>I have to sync two CVS repositories located on two non-
>>>connected networks.  
>>
>>If you MUST do this (and it is almost certain that you do
>>not need to, but that's another story)
> 
> 
> I assume that you've never had to develop under DOD-enforced contract
> requirements, or you wouldn't have written that.  Anyway, the justification

Nope.  I was thinking of DoD, that's why I wrote "almost".  The DoD 
leads the list of "industries that don't understand digital security". 
  (And no, I'm not thumbing my nose at you for working there)

> Duly noted.  For the record, does anyone have a suggestion for an
> open-source CM tool which _is_ designed for use in this manner?  Again,
> assuming that the repositories must be on physically disjunct networks, such
> that any synchronization would have to be via hand-ported media in
> human-readable format (ie, diff patches on CD-R, etc).

I suspect you won't find one, since, as mentioned before, this is 
fundamentally bad practice with a simple solution - single repository 
operation.  (A "real" solution for this is mindbogglingly complicated, 
due to all the special cases that can arise).  I know that the subject 
comes up a lot, but I've never seen anyone come back with a solid 
answer.  I think most of the solutions that get implemented are 
painful but workable ones like the one I suggested, or the one you 
outline below.

> I don't debate that this is stretching the intended functionality of CVS,
> but I would nonetheless prefer finding a way to use an open-source CM tool
> such as CVS than rely on a proprietary commercial vendor "solution".

Sounds good.  However, you aren't "stretching", you're "redefining". 
  Please keep in mind that CVS will only be a component in a system of 
your own design.

> I'm still working on a satisfactory algorithm for this, but my current
> thinking bends toward a classic master-slave synchronization effort, ie
> treat one repository as the "master" (main trunk) as the other as a slave
> ("branch").  Then all we have to do is merge the branch back into the main
> trunk, then re-spawn a fresh copy of the master to start a new branch.

That should work OK, but you will have to shutdown the slave during 
synchronization and force update (and possible merge) of all slave 
clients when you bring it back up.

> (Although I'm using the term "branch", I'm not currently planning to make
> use of actual CVS branches...should I?  Is there room for an efficient
> optimization by using that feature?)

Almost certainly not, perhaps someone else is more inspired than I. 
The one thing I think might help would be per-file branches, which I 
mention below.

> This visualizes my approach:
> 
> (RepoA and RepoB are Repositories on Networks NetA and NetB.)
> 
> RepoA
> -
> foo.c @  1.1
> foo.c -> 1.2
> foo.c -> 1.3
> 
> 
copy RepoA to RepoB
>>>
> |
> | \
> |   \
> | \
> |   \
> | \
> |   \
> \/   _|
> 
> RepoA   RepoB
> -   
> foo.c @  1.3  | foo.c @  1.3
> foo.c -> 1.4  |
>   | foo.c -> 1.4 (alpha mod)
> foo.c -> 1.5  |
> foo.c -> 1.6  |
>   | foo.c -> 1.5 (bravo mod)
> foo.c -> 1.7  |
> 
> 
time to sync changes!
>>>
> 
>   | collect all diffs
>   |to all files
>   |(2 diffs for foo.c),
>   |
>  <--  transport to RepoA
>   |
> foreach file, |
> foreach diff, |
> apply & comm. |
>   |
> foo.c -> 1.8  |
> foo.c -> 1.9  |
>   |
> foo.c now has |
>   alpha and   |
>   bravo mods  |
>   |

WHOOT!  WHOOT!  WHOOT!  Danger, Will Robinson!  Are you ABSOLUTELY 
CERTAIN that the person merging the databases will be able to merge 
the files?  If not, you're either going to have to shuttle developers 
into and out of the RepoA location (with both repos down in the 
meantime), or prepare for long periods of broken trees.

Another thing that you could do here would be per-file branches, only 
for files that have conflicts like this.  So your file would now 
history like:

foo.c
  |
  | \
  |   \
  | \
  |   \
  | \
  |   \
  \/   _|

 trunk   diff_branch_2002_08_09
  -   
  foo.c @  1.3  | foo.c @  1.3.1.1
  foo.c -> 1.4  |
| foo.c -> 1.3.1.2 (alpha mod)
  foo.c -> 1.5  |
  foo.c -> 1.6  |
| foo.c -> 1.3.1.3 (bravo mod)
  foo.c -> 1.7  |

  |   /
  | /
  |   /
  | /
  |   /
  | /
  |
  V

   foo.c -> 1.8 (merged)

With this, you still have a viable archive (provided foo.c isn't the 
file that everything else depends on), and may be able to overwrite 
RepoB with this and proceed for the next cycle while the foo.c 
developers do the merg

RE: sync repositories

[Paul Sander]

There has been a fair amount of discussion about this topic in the past,
and I believe that someone has a working implementation that follows this
model:

Each site owns its own trunk.  Each site creates a branch that is used for
importing from the other site(s); these branches map to the trunk(s) at the
remote site(s).  No local commits are permitted on the import branches.
Each site keeps a list of branches to export to the other site(s), and
tracks the latest exported versions on each export branch.

To send an update from a remote site, the latest exported versions table and
the export branch table are consulted, and all versions that have never
before been exported are packaged up and sent (and the tables are updated
as needed).  Tags are also sent out in an appropriate manner.

To receive an update, the received versions are checked into the import
branch(es) as needed, and the tags are translated accordingly.

Note that all sites must perform periodic cross-merges to keep their sources
synchronized, but that is the same in practice as having features branches
in a single repository.

--- Forwarded mail from [EMAIL PROTECTED]

> > I have to sync two CVS repositories located on two non-
> > connected networks.  
>
> If you MUST do this (and it is almost certain that you do
> not need to, but that's another story)

I assume that you've never had to develop under DOD-enforced contract
requirements, or you wouldn't have written that.  Anyway, the justification
for the requirement is irrelevant; take it as a given that such requirements
do exist from time to time.  Treat it as an additional challenge on which to
flex your creativity :-)

> Please examine two messages from the archives of this
> list entitled "How I repaired my repository" 

Here are the links, for anyone who had trouble finding the archives (I
did)...

http://mail.gnu.org/pipermail/info-cvs/2002-July/029157.html
http://mail.gnu.org/pipermail/info-cvs/2002-July/029158.html

> Note that CVS was not designed for multiple repository operation.

Duly noted.  For the record, does anyone have a suggestion for an
open-source CM tool which _is_ designed for use in this manner?  Again,
assuming that the repositories must be on physically disjunct networks, such
that any synchronization would have to be via hand-ported media in
human-readable format (ie, diff patches on CD-R, etc).

I don't debate that this is stretching the intended functionality of CVS,
but I would nonetheless prefer finding a way to use an open-source CM tool
such as CVS than rely on a proprietary commercial vendor "solution".

I'm still working on a satisfactory algorithm for this, but my current
thinking bends toward a classic master-slave synchronization effort, ie
treat one repository as the "master" (main trunk) as the other as a slave
("branch").  Then all we have to do is merge the branch back into the main
trunk, then re-spawn a fresh copy of the master to start a new branch.

(Although I'm using the term "branch", I'm not currently planning to make
use of actual CVS branches...should I?  Is there room for an efficient
optimization by using that feature?)

This visualizes my approach:

(RepoA and RepoB are Repositories on Networks NetA and NetB.)

RepoA
-
foo.c @  1.1
foo.c -> 1.2
foo.c -> 1.3

>>> copy RepoA to RepoB
|
| \
|   \
| \
|   \
| \
|   \
\/   _|

RepoA   RepoB
-   
foo.c @  1.3  | foo.c @  1.3
foo.c -> 1.4  |
  | foo.c -> 1.4 (alpha mod)
foo.c -> 1.5  |
foo.c -> 1.6  |
  | foo.c -> 1.5 (bravo mod)
foo.c -> 1.7  |

>>> time to sync changes!

  | collect all diffs
  |to all files
  |(2 diffs for foo.c),
  |
 <--  transport to RepoA
  |
foreach file, |
foreach diff, |
apply & comm. |
  |
foo.c -> 1.8  |
foo.c -> 1.9  |
  |
foo.c now has |
  alpha and   |
  bravo mods  |
  |
  
>>> copy RepoA to RepoB
|
| \
|   \
| \
|   \
| \
|   \
\/   _|

RepoA   RepoB
-   
foo.c @  1.9  | foo.c @  1.9
  |
  V

...of course, this is of less help to Piet, who already has split
repositories, and may or may not have a common base version from which to
apply a "merge".  However, I have the advantage of having not yet split my
development, so I still have a chance to plan things out and initialize the
sets accordingly...

I haven't worked out the mechanics of extracting the diffs, but with a bit
of Perl and what-not it shouldn't be difficult to preserve log messages.  I
thought about trying to override the author/date attributes of the diffs,
but even if that were feasible and convenient, it would be a little weird if
"rev 1.8" seemed to be datestamped before "1.7"...therefore, I'll probably
just append the o

RE: sync repositories

[Zieg, Mark]

> > I have to sync two CVS repositories located on two non-
> > connected networks.  
>
> If you MUST do this (and it is almost certain that you do
> not need to, but that's another story)

I assume that you've never had to develop under DOD-enforced contract
requirements, or you wouldn't have written that.  Anyway, the justification
for the requirement is irrelevant; take it as a given that such requirements
do exist from time to time.  Treat it as an additional challenge on which to
flex your creativity :-)

> Please examine two messages from the archives of this
> list entitled "How I repaired my repository" 

Here are the links, for anyone who had trouble finding the archives (I
did)...

http://mail.gnu.org/pipermail/info-cvs/2002-July/029157.html
http://mail.gnu.org/pipermail/info-cvs/2002-July/029158.html

> Note that CVS was not designed for multiple repository operation.

Duly noted.  For the record, does anyone have a suggestion for an
open-source CM tool which _is_ designed for use in this manner?  Again,
assuming that the repositories must be on physically disjunct networks, such
that any synchronization would have to be via hand-ported media in
human-readable format (ie, diff patches on CD-R, etc).

I don't debate that this is stretching the intended functionality of CVS,
but I would nonetheless prefer finding a way to use an open-source CM tool
such as CVS than rely on a proprietary commercial vendor "solution".

I'm still working on a satisfactory algorithm for this, but my current
thinking bends toward a classic master-slave synchronization effort, ie
treat one repository as the "master" (main trunk) as the other as a slave
("branch").  Then all we have to do is merge the branch back into the main
trunk, then re-spawn a fresh copy of the master to start a new branch.

(Although I'm using the term "branch", I'm not currently planning to make
use of actual CVS branches...should I?  Is there room for an efficient
optimization by using that feature?)

This visualizes my approach:

(RepoA and RepoB are Repositories on Networks NetA and NetB.)

RepoA
-
foo.c @  1.1
foo.c -> 1.2
foo.c -> 1.3

>>> copy RepoA to RepoB
|
| \
|   \
| \
|   \
| \
|   \
\/   _|

RepoA   RepoB
-   
foo.c @  1.3  | foo.c @  1.3
foo.c -> 1.4  |
  | foo.c -> 1.4 (alpha mod)
foo.c -> 1.5  |
foo.c -> 1.6  |
  | foo.c -> 1.5 (bravo mod)
foo.c -> 1.7  |

>>> time to sync changes!

  | collect all diffs
  |to all files
  |(2 diffs for foo.c),
  |
 <--  transport to RepoA
  |
foreach file, |
foreach diff, |
apply & comm. |
  |
foo.c -> 1.8  |
foo.c -> 1.9  |
  |
foo.c now has |
  alpha and   |
  bravo mods  |
  |
  
>>> copy RepoA to RepoB
|
| \
|   \
| \
|   \
| \
|   \
\/   _|

RepoA   RepoB
-   
foo.c @  1.9  | foo.c @  1.9
  |
  V

...of course, this is of less help to Piet, who already has split
repositories, and may or may not have a common base version from which to
apply a "merge".  However, I have the advantage of having not yet split my
development, so I still have a chance to plan things out and initialize the
sets accordingly...

I haven't worked out the mechanics of extracting the diffs, but with a bit
of Perl and what-not it shouldn't be difficult to preserve log messages.  I
thought about trying to override the author/date attributes of the diffs,
but even if that were feasible and convenient, it would be a little weird if
"rev 1.8" seemed to be datestamped before "1.7"...therefore, I'll probably
just append the original (RepoB) author and date onto the log message as
each diff is re-applied.

Comments vigorously solicited!

Mark Zieg

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Permissions issue

[Steele, Lynne]

All,

We are trying to stand up CVS on a Windows 2000 machine.  We can get things
checked in locally, but when we try to push them to the server, we get a
permissions failure of unrecognized user/password.

Thanks,

Lynne

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: (OT) Mailing List Commands

[Derek Robert Price]

Mike Ayers wrote:

>
> Mark Cooper wrote:
>
>> The web page refers to a FAQ, but doesn't give a link to one.
>
>
> Hmm??  A CVS FAQ?  I'm not aware of one.


There's one up on .  Follow the link in the left 
navbar to the CVS FAQ.  It isn't extraordinarily well maintained, but 
volunteers are welcome!

>> Other mailing lists I subscribe to provide such things as '--LongSig' to
>> truncate long, corporately applied signatures from the end of mails 
>> (hence
>> I apologise for mine). They also provide commands for obtaining 
>> re-sends of
>> all messages in a thread or a list of messages with certain text in 
>> iether
>> the subject line or message body (helps to stop from posting the same
>> question as the group spent 3 weeks arguing over a short while 
>> previously).
>
>
> All you get here is FTP hosted monthly archives.  Welcome to the 
> old school!


 keeps a pretty good searchable archive too. 
 There's supposed to be one on cvshome.org, but it's pretty broken at 
the moment.

Derek

-- 
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at http://ximbiot.com
-- 
Unix _IS_ user friendly - it's just selective about who its friends are!




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: (OT) Mailing List Commands

[Mike Ayers]

Mark Cooper wrote:
> 
> Does anyone know where the list of recognisable embedded commands for this
> mailing list can be found?

Well, the web admin page, as listed below, at 
http://mail.gnu.org/mailman/listinfo/info-cvs, contains the options. 
There aren't many, though.

> The web page refers to a FAQ, but doesn't give a link to one.

Hmm??  A CVS FAQ?  I'm not aware of one.

> Other mailing lists I subscribe to provide such things as '--LongSig' to
> truncate long, corporately applied signatures from the end of mails (hence
> I apologise for mine). They also provide commands for obtaining re-sends of
> all messages in a thread or a list of messages with certain text in iether
> the subject line or message body (helps to stop from posting the same
> question as the group spent 3 weeks arguing over a short while previously).

All you get here is FTP hosted monthly archives.  Welcome to the old 
school!



Oil, meet Water.  Water, Oil.  I'm sure you'll be great friends.

England, meet Digital Age.  Digital Age, England.  I'm sure you'll be 
great friends.

Bwaaahahahahahaha!!!

(Sorry.  Sometimes I just can't help myself.  But Mr. Grenyer's siggy 
had me in the mood, and you pointed it out...)


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: sync repositories

[Mike Ayers]

Zieg, Mark wrote:
>>I have to sync two CVS repositories located on two non-
>>connected networks.  (yep, this means tape/CDROM transports,
>>I know it sounds silly).  I was wondering if there is a
>>better way than creating incremental tar files on both sides
>>and applying them on the other side. Luckily, the chances
>>that two persons from the two sites are working on the same
>>file are minimal, but I would like to prevent possible sync
>>errors if it occurs.

If you MUST do this (and it is almost certain that you do not need 
to, but that's another story), then please examine two messages from 
the archives of this list entitled "How I repaired my repository" 
dated 30Jun02 - my summary of how I repaired a corrupt repository from 
a good sandbox and Eric Siegerman's additional suggestions.  In your 
case, it becomes "How to sync your repository", the "restored archive" 
is your "repository to be updated", and the "preserved sandbox" is 
your "sandbox created from the other repository".

Note that there is significant potential for disaster.  Note that you 
will have to do this again, in the other direction.  Note that CVS was 
not designed for multiple repository operation.  Note that this is 
generally a bad idea.  Is a pattern emerging here?

> Silly or not, I'm going to have to do the same thing in a week or so -- and
> it will probably become a regular part of our CM process.  In certain
> industries, the need for private, disjunct networks is an unbending fact of
> life.

We can categorize these industries as "industries which do not 
understand computer security", and yes, we'll be stuck with them for 
some time to come.

> I haven't come up with a solid plan for this that I liked yet, but I'll
> watch the list to see if anyone has a good existing method, and I'll share
> whatever I come with in-house...

As much as I discourage doing this, I am interested in whatever you 
settle on.


/|/|ike


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Share repository between Linux and XP server

[Gianni Mariani]

Paul Grenyer wrote:

>*** Before acting on this e-mail or opening any attachment you are advised to read 
>the disclaimer at the end of this e-mail ***
>
>Hi
>
>  
>
>>Bear in mind that Linux is case-sensitive but Windows is only
>>case-preserving.  If you're not careful, some weirdness may
>>result from that.
>>
>>And (you probably know this, but I'll say it anyway) even though
>>you're sharing the repo, DON'T share sandboxes; that way lies
>>newline chaos.
>>
>>
>
>It also might be worth running CVSNT (www.cvsnt.org) on both Linux and XP
>(Yes, there is a CVSNT build for Linux!).
>
>  
>

I'm not sure - but I'd be concerned about CVSNT not coping with file 
permissions for Unix clients !

BTW - we run out cvspserver on Linux and it works well.  We have a rule 
that any new files go into the tree in lower case - except for third 
party files.  That seems to get around most of the problems although 
I've had to jump into the repo to remove some corrupted upper case files 
that engrs also tried to remove and add again as lower case - no big deal.

G



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Share repository between Linux and XP server

[Paul Grenyer]

*** Before acting on this e-mail or opening any attachment you are advised to read the 
disclaimer at the end of this e-mail ***

Hi

> Bear in mind that Linux is case-sensitive but Windows is only
> case-preserving.  If you're not careful, some weirdness may
> result from that.
> 
> And (you probably know this, but I'll say it anyway) even though
> you're sharing the repo, DON'T share sandboxes; that way lies
> newline chaos.

It also might be worth running CVSNT (www.cvsnt.org) on both Linux and XP
(Yes, there is a CVSNT build for Linux!).

Regards
Paul

Paul Grenyer
Software Development Engineer
http://www.paulgrenyer.co.uk
--LongSig

communisis chorleys ltd
Computer Bureau
Manston Lane
Crossgates
Leeds
LS15 8AH

Telephone +44 (0)113 225 5271
Fax   +44 (0)113 225 5921
Email [EMAIL PROTECTED]


**
Please note: This e-mail and its attachments contain only the opinions of the sender 
and do not necessarily reflect the policy(s) of the communisis group in general. 

Employees of the communisis group are required not to make any defamatory statements 
and not to infringe or authorise any infringement of copyright or any other legal 
right by e-mail. Any such communication is therefore outside the scope of employment 
of the individual concerned. The communisis group will not accept any liability in 
respect of such a communication.

Confidentiality: This e-mail and any attachments, together with their contents, are 
confidential unless otherwise explicitly stated in writing by the sender of this 
e-mail and are for the intended recipient only. If they have come to you in error you 
must not take any action in respect of them, which includes but is not limited to 
reproducing, sending or storing them, other than to notifying the sender immediately 
of the mistake, and deleting the e-mail, any attachments and any reproductions made by 
replying to it.

Viruses: This e-mail and any attachments have been scanned for viruses but we cannot 
guarantee that they are virus free. The recipient should check this e-mail and any 
attachments for viruses. The communisis group accepts no responsibility for any damage 
caused by any virus transmitted by this e-mail or any of its attachments. In the event 
of any unauthorised copying or forwarding, the recipient will be required to indemnify 
the communisis group against any claim for loss or damage caused by any viruses or 
otherwise.
**



This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Share repository between Linux and XP server

[Eric Siegerman]

On Fri, Aug 09, 2002 at 09:09:37AM +0200, Anders Truelsen wrote:
> From: Mads Pultz [mailto:[EMAIL PROTECTED]] 
> Sent: 9. august 2002 07:27
> To: [EMAIL PROTECTED]
> Subject: Share repository between Linux and XP server
> 
> > I have a dual-boot boot machine. Regardless of the OS I booted I want to
> > work on the same repository.
>
> If Linux and XP have a common filesystem that both can read it shouldn't
> be a problem.

Bear in mind that Linux is case-sensitive but Windows is only
case-preserving.  If you're not careful, some weirdness may
result from that.

And (you probably know this, but I'll say it anyway) even though
you're sharing the repo, DON'T share sandboxes; that way lies
newline chaos.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|  |  /
Anyone who swims with the current will reach the big music steamship;
whoever swims against the current will perhaps reach the source.
- Paul Schneider-Esleben

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: sync repositories

[Zieg, Mark]

> I have to sync two CVS repositories located on two non-
> connected networks.  (yep, this means tape/CDROM transports,
> I know it sounds silly).  I was wondering if there is a
> better way than creating incremental tar files on both sides
> and applying them on the other side. Luckily, the chances
> that two persons from the two sites are working on the same
> file are minimal, but I would like to prevent possible sync
> errors if it occurs.

Silly or not, I'm going to have to do the same thing in a week or so -- and
it will probably become a regular part of our CM process.  In certain
industries, the need for private, disjunct networks is an unbending fact of
life.

I haven't come up with a solid plan for this that I liked yet, but I'll
watch the list to see if anyone has a good existing method, and I'll share
whatever I come with in-house...

-Mark Z

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

(OT) Mailing List Commands

[Mark Cooper]

Does anyone know where the list of recognisable embedded commands for this
mailing list can be found?

The web page refers to a FAQ, but doesn't give a link to one.

Other mailing lists I subscribe to provide such things as '--LongSig' to
truncate long, corporately applied signatures from the end of mails (hence
I apologise for mine). They also provide commands for obtaining re-sends of
all messages in a thread or a list of messages with certain text in iether
the subject line or message body (helps to stop from posting the same
question as the group spent 3 weeks arguing over a short while previously).

Mark Cooper



- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Any views or opinions presented in this Email message are solely those of
the author and do not necessarily represent those of the Microlise Group
unless otherwise specifically stated.
Email communications are not necessarily secure and therefore the Microlise
Group does not accept legal responsibility for the contents of this
message.

If you are not the intended recipient and have received this message in
error, please notify Microlise immediately.

Microlise Group Limited +44 (0)1773 713311



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: When is the WinCvs Stable release?

[Mark Cooper]

Arcin Bozkurt wrote:

> This is not related to CVS directly but I am sure there are people who
would
 > know the answer...
 > WinCVS, after its 1.2 release has gone through 8 beta releases in the
1.3
 > product line.
 >
 > Does anyone know when WinCvs expects to make a stable release of 1.3 ?

You might try subscribing to the cvs gui mailing list and asking the
question there.

http://groups.yahoo.com/subscribe/cvsgui

A cursory glance at the http://cvsgui.sourceforge.net/ web site doesn't
give any relevant info.

Good Luck

Mark Cooper





- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Any views or opinions presented in this Email message are solely those of
the author and do not necessarily represent those of the Microlise Group
unless otherwise specifically stated.
Email communications are not necessarily secure and therefore the Microlise
Group does not accept legal responsibility for the contents of this
message.

If you are not the intended recipient and have received this message in
error, please notify Microlise immediately.

Microlise Group Limited +44 (0)1773 713311



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

When is the WinCvs Stable release?

[Arcin Bozkurt]

 
This is not related 
to CVS directly but I am sure there are people who would know the 
answer...
WinCVS, after its 
1.2 release has gone through 8 beta releases in the 1.3 product line. 

 
Does anyone know 
when WinCvs expects to make a stable release of 1.3 ?
 
-arcin